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1 SYSTEM AND METHOD FOR PUBLISHING AND ACCESSING 

2 APPLICATION APIS ON A GENERIC TERMINAL 

3 

4 Background 

5 The present application relates to the interaction of applications using application 

6 program interfaces. 
7 

8 There is a continually increasing number of terminals in use today, such as mobile 



9 telephones, PDAs with wireless communication capabilities, personal computers, self service 

10 kiosks and two-way pagers. Software applications which run on these devices increase their 

1 1 utility. For example, a mobile phone may include an application which retrieves the weather for 

12 a range of cities, or a PDA may include an application that allows a user to shop for groceries. 



13 These software applications take advantage of connectivity to a network in order to provide 

14 timely and useful services to users. However, due to the restricted resources of some devices, 

1 5 developing software applications for a variety of devices remains a difficult and time-consuming 

16 task. 
17 

1 8 At present there is no public standard for defining and publishing application access 

19 APIs. Currently, wireless platforms and implementations offer some customized interaction 

20 solutions that assume explicit knowledge of all available applications and corresponding APIs 

21 installed on the device. The capability of device-hosted wireless applications to interact is 

22 predefined by current runtime environments and current applications' built-in knowledge of this 

23 environment. All decisions regarding the interaction options and available external APIs are 

24 made during the design and development phase with no run-time adjustment or extension 



1 possible. The interactions between applications are currently implemented using the coding 

2 platform native for the supporting runtime environment and interacting applications. 
3 

4 Disadvantages with the current application interaction approach include: changes in 

5 configuration or version of a single software component often require the reinstall of a large 

6 number of dependent or related applications; previously installed software components are 

7 unable to communicate with software provisioned and installed at a later date; and inability to 

8 seamlessly upgrade existing software or change components in an interdependent software suite. 
9 

10 ISystems and methods are disclosed for customized interaction of applications to obviate 

1 1 or mitigate at least some of the ^bove-presented disadvantages. 
12 

13 Summary 

14 Disadvantages with the current application interaction approach include: changes in 

15 configuration or version of a single software component often require the reinstall of a large 

16 number of dependent or related applications; previously installed software components are 

17 unable to communicate with software provisioned and installed at a later date; and inability to 

18 seamlessly upgrade existing software or change components in an interdependent software suite. 

19 Contrary to the current interaction approach there are provided systems and methods for 

20 providing dynamic interaction between a pair of application programs by a platform neutral 

21 interface of a terminal, the pair of applications including a requestor application desiring access 

22 to a target application. One such method can include registering and/or distributing 

23 automatically or upon request access information of the target application, such that the access 

24 information includes published access information made available in a data structure for retrieval 



1 by the platform neutral interface. The term registering as used herein can refer to specific 

2 communication with and/or to a directory or repository and/or distribution automatically or upon 

3 request. Under such a method, an access request is received by a platform neutral interface of a 

4 terminal from the requestor application, such that the access request includes request content 

5 corresponding to the published access information of the target application. An interface 

6 component is obtained by using the request content to search the data structure, such that the 

7 interface component is configured for enabling communication between the platform neutral 

8 interface and the target application in an access format expected by the target application. The 

9 obtained interface component is employed by the platform neutral interface to satisfy the access 
10 request of the requestor application for interaction with the target application. 

11 

12 A method is also disclosed for providing dynamic interaction between a pair of 

1 3 application programs by a platform neutral interface of a terminal, the pair of applications 

14 including a requestor application desiring access to a target application, the method comprising 

15 the steps of: registering and/or distributing access information of the target application, the 

16 access information including published access information made available in a data structure for 

17 retrieval by the platform neutral interface; receiving an access request by the platform neutral 

1 8 interface from the requestor application, the access request including request content 

19 corresponding to the published access information of the target application; obtaining an 

20 interface component by using the request content to search the data structure, the interface 

21 component configured for enabling communication between the platform neutral interface and 

22 the target application in an access format expected by the target application; and employing the 



1 interface component by the platform neutral interface to satisfy the access request of the 

2 requestor application for interaction with the target application. 
3 

4 Also provided is a terminal for providing dynamic interaction between a pair of 

5 application programs in a platform neutral environment provided by a runtime environment of 

6 the terminal, the pair of applications including a requestor application desiring access to a target 

7 application, the terminal comprising: a data structure for registering access information of the 

8 target application, the access information including published access information; an interface 

9 module for providing the platform neutral environment, the interface module configured for 

10 receiving an access request from the requestor application, the access request configured to 

1 1 include request content corresponding to the published access information of the target 

12 application, the published access information of the data structure retrievable by the interface 

13 module; and an interface component coupled to the interface module retrievable by using the 

14 request content to search the data structure, the interface component configured for enabling 

1 5 communication between the interface module and the target application in an access format 

16 expected by the target application; wherein employing the interface component by the interface 

17 module satisfies the access request of the requestor application in interaction with the target 

18 application. 
19 

20 A computer program product is further disclosed for providing dynamic interaction 

21 between a pair of application programs in a platform neutral environment provided by a runtime 

22 environment of a terminal, the pair of applications including a requestor application desiring 

23 access to a target application, the computer program product comprising: a computer readable 



1 medium; a data structure module stored on the computer readable medium for registering access 

2 information of the target application, the access information including published access 

3 information; an interface module coupled to the data structure module for providing the platform 

4 neutral environment, the interface module configured for receiving an access request from the 

5 requestor application, the access request configured to include request content corresponding to 

6 the published access information of the target application, the published access information of 

7 the data structure module retrievable by the interface module; and an interface component 

8 module coupled to the interface module, the interface module configured for containing an 

9 interface element retrievable by using the request content to search the data structure module, the 

10 interface component configured for enabling communication between the interface module and 

1 1 the target application in an access format expected by the target application; wherein employing 

12 the interface component by the interface module satisfies the access request of the requestor 

13 application in interaction with the target application. 
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Brief Description Of The Drawings 
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These and other features will become more apparent in the following detailed description 
in which reference is made to the appended example drawings, wherein: 
Figure 1 is a block diagram of a network system; 



19 



Figure 2 is a block diagram of a generic terminal of Figure 1; 



20 



Figure 3 shows a processing framework of the terminal of Figure 2; 



21 



Figure 4 shows application interaction using a dedicated handler for the framework of 



22 



Figure 3; 



23 



Figure 5 is an alternative example of the interface module of Figure 3 as an Integration 



24 



Engine; 



1 Figure 6 is an example of runtime flow of the integration engine of Figure 3; and 

2 Figure 7 shows an example operation of interaction between two applications of Figure 1. 
3 

4 Detailed Description 

5 Network System 

6 Referring to Figure 1 , a network system 10 comprises a plurality of terminals 100 for 

7 interacting with one or more application servers 110 accessed by a management server 106, via a 

8 coupled Wide Area Network (WAN) 104 such as but not limited to the Internet. The terminals 

9 100 receive application programs 107 from the application server 1 10 via the server 106 over the 

10 network 104. The generic terminals 100 can be such as but not limited to wired devices such as 

1 1 desktop terminals 116, wireless devices 101, PDAs, self-service kiosks and the like. Further, the 

12 system 10 can also have a gateway server 1 12 for connecting the desktop terminals 1 16 (or other 

13 wired devices) via a Local Area Network (LAN) 1 14 to the server 106. 
14 

15 Further, the system 10 can have a wireless network 102 for connecting the wireless 

16 devices 101 to the WAN 104. It is recognized that other terminals and computers (not shown) 

17 could be connected to the server 106 via the WAN 104 and associated networks other than as 

18 shown in Figure 1. The generic terminals 100, wireless devices 101 and personal computers 116 

19 are hereafter referred to as the terminal 100 for the sake of simplicity. Further, the networks 102, 

20 104, 1 12 of the system 10 will hereafter be referred to as the network 104, for the sake of 

21 simplicity. It is recognized that there could be multiple servers 106, 110, and/or that the 

22 functionality of the servers 106 and 1 10 could be combined, if desired. It is further recognized 

23 that the servers 106, 110 could be implemented by a service provider 118 providing a schema- 



1 defined service, such as a web service by example. Further, the terminals 100 could also operate 

2 as stand-alone devices when obtaining and executing the applications 107. For example, the 

3 application can be loaded onto terminals via a computer readable medium 212, (see Figure 2), as 

4 further defined below. 
5 

6 The system 10 facilitates interaction between a number of applications 107, labeled for 

7 example as "A", "B", "C" and "D", distributed on one of the terminals 100 (i.e. local interaction 

8 - for example between application "A" and "C") and between terminals 100 (i.e. remote 

9 interaction - for example between applications "B" and "D"). The applications 107 interact 

10 through an interface and data structures module 312 (see Figure 2) expressed in a platform 

1 1 neutral structured definition language (such as but not limited to XML) and/or in a platform 

12 neutral scripting language (such as but not limited to ECMAScript). The applications 107 

13 communicate through Application Program Interfaces (APIs) 122 and access extensions 124 

14 (hereafter referred to as access handlers 124). The APIs 122 and handlers 124 can be retrieved 

15 from a repository or database 120. It is recognized that the database 120 could be made available 

16 by the service 1 18 or an independent database server 126. The system also provides for 

1 7 execution of API declared operations and matching an API with an application request. The 

18 language used to express the interface module 312 is hereafter referred to as XML for simplicity 

19 without loss of generality; it is specifically contemplated that in each such instance a different 

20 platform neutral structured definition language or scripting language could be used depending 

2 1 upon implementation choices and/or constraints. 
22 

23 Generic Terminal 



1 Referring to Figure 2, the terminals 100 are such as but not limited to mobile telephones 

2 (or other wireless devices), PDAs, two-way pagers or dual-mode communication terminals. The 

3 terminals 100 include a network connection interface 200, such as a wireless transceiver or a 

4 wired network interface card or a modem, coupled via connection 21 8 to a terminal 

5 infrastructure 204. The connection interface 200 is connectable during operation of the 

6 terminals 100 to the network 104, such as to the wireless network 102 by, for example, RF links 

7 (see Figure 1), which enables the terminals 100 to communicate with each other and with 

8 external systems (such as the server 106 - see Figure 1) via the network 104 and to coordinate the 

9 requests/response messages 105 between the terminals 100 and the servers 106, 1 10, 126. The 

10 network 104 supports the transmission of the application programs 107 in the requests/response 

1 1 messages 105 between terminals 100 and external systems, which are connected to the network 

12 104. The network 104 may also support voice communication for telephone calls between the 

13 terminals 100 and terminals which are external to the network 104. A wireless data transmission 

14 protocol can be used by the wireless network 102, such as but not limited to DataTAC, GPRS or 

15 CDMA. It is recognized that interactions between terminals 100 can also refer to remote 

16 interactions between the applications 107. 
17 

18 Referring again to Figure 2, the terminals 100 also have a user interface 202, coupled to 

19 the terminal infrastructure 204 by connection 222, to facilitate interaction with a user (not 

20 shown). The user interface 202 can includes one or more user input devices such as but not 

21 limited to a QWERTY keyboard, a keypad, a trackwheel, a stylus, a mouse, a microphone and 

22 the user output device such as an LCD screen display and/or a speaker. If the screen is touch 



1 sensitive, then the display can also be used as the user input device as controlled by the terminal 

2 infrastructure 204. 
3 

4 Referring again to Figure 2, operation of the terminal 100 is enabled by the terminal 

5 infrastructure 204. The terminal infrastructure 204 includes the computer processor 208 and the 

6 associated memory module 210. The computer processor 208 manipulates the operation of the 

7 network interface 200, the user interface 202 and a framework 206 (see Figure 3) of the 

8 communication terminal 100 by executing related instructions, which are provided by an 

9 operating system and client application programs 107 located in the memory module 210; the 

10 computer processor 208 can include one or more processing elements that may include one or 

1 1 more general purpose processors and/or special purpose processors (e.g., ASICs, FPGAs, DSPs, 

12 etc). Further, it is recognized that the terminal infrastructure 204 can include a computer 

13 readable storage medium 212 coupled to the processor 208 for providing instructions to the 

14 processor for loading and executing client application programs 107. The computer readable 

15 medium 212 can include hardware and/or software such as, by way of example only, magnetic 

16 disks, magnetic tape, optically readable medium such as CD/DVD ROMS, and memory cards. 

17 In each case, the computer readable medium 212 may take the form of a small disk, floppy 

18 diskette, cassette, hard disk drive, solid state memory card, or RAM provided in the memory 

19 module 210. It should be noted that the above listed example computer readable mediums 212 

20 can be used either alone or in combination. 
21 

22 Processing Framework 

23 Referring to Figure 2, a client runtime environment is provided by the processing 

24 framework 206. Multiple such runtime environments could potentially be available for use by 



1 the processing framework 206 of a given terminal 100. The framework 206 of the terminal 100 

2 is coupled to the infrastructure 204 by the connection 220 and is an interface to the terminal 100 

3 functionality of the processor 208 and associated operating system of the infrastructure 204. 

4 The client runtime environment of the terminals 100 is preferably capable of generating, hosting 

5 and executing the client application programs 107 on the terminal 100; if multiple runtime 

6 environments are available, a particular one can be selected for use with a given application 

7 program 107. Referring again to Figure 1, the client runtime environment provided by the 

8 terminal 100 can be configured to make the terminals 100 operate as web clients of the web 

9 services (of the web service 118). It is recognized that the client runtime environment can also 

10 make the terminals 100 clients of any other generic schema-defined services supplied by the 

11 service 118. 
12 



13 The terminal runtime environment of the framework 206 preferably supports the 

14 following basic functions for the resident executable versions of the client application programs 

15 1 07 (see Figure 2), such as but not limited to: 

16 provide the platform neutral interface module 3 12 for facilitating local and/or remote 

1 7 interaction between applications 1 07; 

18 provide a communications capability to send messages 105 to the server 106 via the 

19 network 104; 

20 provide data input capabilities by the user on an input device of the terminals 100 to 

21 supply data parts for outgoing messages 105 to the server 106; 

22 provide data presentation or output capabilities for response messages 105 (incoming 

23 messages) or uncorrelated notifications of the server 106; 



1 provide data storage services to maintain local client data in the memory module 210 

2 and/or computer readable medium 212 (see Figure 2) of the terminal 100; and 

3 provide an execution environment for a scripting language for coordinating operation of 

4 the application 107. 
5 

6 Further, specific functions of the client runtime environment can include such as but not 

7 limited to service support for language, coordinating memory allocation, networking, 

8 management of data during I/O operations, coordinating graphics on an output device of the 

9 terminals 100 and providing access to core object oriented classes and supporting files/libraries. 

10 Examples of the runtime environments implemented by the terminals 100 can include such as but 

1 1 not limited to Common Language Runtime (CLR) by Microsoft and Java Runtime Environment 

1 2 (JRE) by Sun Microsystems. 
13 

14 Referring to Figure 3, the processing framework 206 can also have other modules such as 

15 but not limited to an Application Manager 306 and a provisioning manager 311. The 

16 provisioning manager 31 1 manages the provisioning of the software applications 107 on the 

17 terminal 100. Application provisioning can include storing, retrieving, downloading and 

18 removing applications 107, and configuring the application programs 107 for access to remote 

19 applications 107 via the cooperating interface modules 312 on linked terminals 100. The 

20 Application Manager 306 can be used to interact with the user interface 202 (see Figure 2), 

21 manage application lifetime etc. It is recognized that other configurations of the processing 

22 framework 206 with respective managers 306, 3 1 1 in addition to or other than shown can be 

23 implemented, as desired. 



1 

2 Referring again to Figure 3, the interface module 312 employs a series of interface 

3 components, such as APIs 124, to coordinate communication between a requesting application 

4 400 (see Figure 4) and the target applications 107. The interface module 312 can also use other 

5 interface components, such as the access handlers 122, to run as a plugin inside the interaction 

6 module 312 and to mediate interactions between the interaction requestor 400 and the target 

7 application 107, wherein the target application is expressed in a language other than the platform 

8 neutral language of the module 312 (e.g. convert XML-based standard interface calls from the 

9 module 312 into application specific native calls appropriate for communication with the native 

10 based target application program 107). It is recognized that the target application can be 

1 1 expressed in the native language of the runtime environment or otherwise expressed in a 

12 language different from the structured platform neutral language of the interface module 312. 
13 

14 The Access Handlers 122 can be developed to run as a plugin inside the interface module 

15 312 and may mediate the interactions between the application 107 acting as an interaction 

16 requestor and the target application 107. The Handler 122 provides API support in terms of 

17 internal constructs of the target application 107 and is target application specific in its 

18 configuration. The Handler 122 allows the interface module 312 to access a published API 124 

19 for an associated application 107 that is not expressed in the platform neutral language of the 

20 interface module 312. The interface module 312 provides the facility to associate new Handlers 

21 122 to the Application URI or other appropriate identifier of a table 302 (see Figure 3) via a 

22 registration interface 504 (see Figure 5). The Handler 122 can verify validity of passed data and 

23 could also optionally contain some access level security related filtering and verification. 



1 

2 Referring again to Figure 3, the interface module 312 employs an Application Profile 

3 table 300 and the Application API Descriptor table 302 for containing access information of the 

4 application 107, the APIs 124, and the handlers 122. The Application Profile table 300 contains 

5 application 107 information provided when a new application 107 is provisioned/installed or 

6 otherwise installed on the terminal 100. The profiles contain all information required for 

7 application publishing (such as but not limited to application URI, description, version, etc.). 

8 The knowledge (publication) of Application Profiles in the table 300 and/or Application API 

9 Descriptors in the table 302 facilitates allows external access to a given application 107 by other 

10 applications through the interaction module 312. The Application API Descriptor table 302 can 

1 1 include a formal descriptor of all APIs supported by a given application 107. The descriptors 

12 could be expressed in any format understandable by the execution runtime such as XML or any 

13 other structured language. These descriptors facilitate a dynamic API discovery mechanism 

14 further described below. It is recognized that the tables 300, 302 could be combined as one 

1 5 table or other data structure. 
16 

17 Application Profile 

18 The Application Profiles of the table 300 could be expressed in any format 

19 understandable by the execution runtime such as XML or any other structured language. The 

20 profiles contain an application identification that can be in the form of a URI and additional 

21 information required for application publishing (such as but not limited to version, description, 

22 etc.). Accordingly, after the application 107 is registered with the interface module 312, the 

23 application 107 can be addressed by other applications using the associated published application 



• » 

1 identifier of the table 320. It is recognized that the application 107 publishing information 

2 should support addressing of local applications 107 (running on the same terminal 100) as well 

3 as addressing of remote applications 107 running at other terminals 100. Remote access uses the 

4 server 106, 116 capable of managing the remote access. For example, the application profiles 

5 corresponding to each application 107 can be defined and provided by the Application Developer 

6 and/or Service Provider when the application 107 is transmitted to the terminal 100, either 

7 explicitly or embedded in the content of the application 107. 
8 

9 The following DTD fragment shows a sample Application Profile declared using XML: 

10 Example : XML-based Application Profile description using DTD 

1 1 <!ELEMENT application (publish, ...)> 
12 

1 3 <!ELEMENT publish (#PCDATA)> 

14 <!ATTLIST publish 

15 uri CDATA #REQUIRED 

1 6 version CDATA #IMPLIED 

1 7 desc CDATA #IMPLIED> 

18 ... 
19 

20 Using the XML definition above the Application Profile fragment for an Address Book 

21 application could be published as: 

22 <publish uri= "AddressBook" version^ "3. 1 " desc= "Contacts manager for device user"/>. 

23 Applications 107 trying to access a local Address Book application 107 on the terminal 100 could 

24 use the "local" URI: " //local/ AddressBook", whereas applications 107 trying to access the 

25 AddressBook application 107 on another terminal 100 (e.g. to insert the terminal user as a new 

26 contact for a remote user), could use "remote" addressing: //remote/ 123987 /AddressBook , where 

27 123987 is a unique ID of the remote terminal 100. 
28 



it 



1 Application API Descriptor 

2 An application access API of the table 302 could be expressed in any format 

3 understandable by the execution runtime such as XML or any other structured language. The 

4 Application API Descriptors can be defined using a standardized subset of expression terms. 

5 The requesting application 107 would possess knowledge on how to match its internal constructs 



6 with the standardized expression terms of the API descriptors. This shared knowledge helps the 

7 use of the Application API Descriptor information and facilitates interactions with the 

8 application 107 publishing this API. For example, if the requestor application 107 uses internal 

9 construct 'rendezvous' it could be matched with a standardized term like 'meeting' or 
10 'appointment' if it appears in the published API descriptor of the target application 107. 
11 



12 The application API could publish descriptors for the following API categories: 

1 3 ■ Information APIs 1 24 

14 o Message (i.e. sending message to the target application 107) 

15 o Data (i.e. accessing data managed by the target application 1 07) 

16 ■ Calling APIs 124 supporting the following calling models 

17 - Start called application 107 and terminate caller 

1 8 - Start called application 1 07 and keep caller running 

19 - Start called application 107 and suspend caller until termination of the called 
20 

21 The following DTD fragment shows an XML based sample for an API Descriptor: 

22 Example: Sample XML based API Descriptor definition using DTD 
23 

24 <! ELEMENT action (op)> 

25 <!-- type can be to call a function, send a message or retrieve information data --> 



1 <!ATTLIST action 

2 api CDATA #REQUIRED 

3 type (call | send | execute ) "execute" 

4 > 

5 <! ELEMENT op (param?,result?)> 

6 <!ATTLIST op 

7 name CDATA #REQUIRED 

8 > 

9 <! ELEMENT param (#PCDATA)> 

1 0 <! ELEMENT result EMPTY> 

1 1 <!ATTUST result 

1 2 type CDATA #REQUIRED 

13 > 

14 

15 Application API Interaction Interfaces 

16 The system 10 provides interaction between applications 107 according to such as but not 

1 7 limited to two modes, namely: 

18 ■ Mode 1 is implemented to comply with the standard interaction interface module 312. 

19 This mode of applications 107 has been designed with knowledge of the interaction 

20 standard supported by the interface module 312 and implements the interface module 312 

21 to convert the requesting application 400 (see Figure 4) calls to internal operations of the 

22 platform neutral environment of the interface module 312; and 

23 ■ Mode 2 is implemented without knowledge of the standard interaction interface module 

24 312. This mode of applications 107 covers a wide range of applications 107 (e.g. current 

25 existing applications) that do not comply with the standard interaction interface module 

26 312. In order to enable interoperability for these applications 107 the interaction 

27 interface module 312 offers a plug-in service provider interface (SPI) 502 (see Figure 5) 

28 for the access handlers 122. The Access Handlers 122 could be developed for a specific 

29 application 107 or API 124 and may support protocol conversion (such as but not limited 

30 to converting XML-based standard interface calls into application specific native calls). 



31 



1 Referring to Figure 4, Application A belongs to mode 1 . Application B belongs to Mode 

2 2. The dedicated Handler 122 was developed to support the API publishing and access to 

3 application B. The requesting application 400 submits an XML based request 404 to the 

4 interface module 312, which calls the Application A by an XML call 406 through the 

5 corresponding API- A 124 completely in the platform neutral environment 402 (e.g. XML), as 

6 supplied by the interaction module 3 12 of the processing framework 206. Alternatively, 

7 Application B is not expressed for interaction in XML, rather a different language used, for 

8 example that of the native runtime environment. Accordingly, the appropriate handler 122 for 

9 the application B is used by the interaction module 312 to convert the XML based request 404 
10 into a native call 408. 

11 

12 The requesting application 400 utilizes the interaction module 312 to access the target 

13 Application A,B using the defined identifier published by the table 300 and/or Access API 

14 Descriptor published by the table 302 (see Figure 3). The interaction module 312 passes on this 

1 5 request 404 to the target Application(s) (either directly 406 or via the Handler 408). Upon 

16 completion or otherwise execution of the request 406, 408, the interaction module 312 passes the 

17 results (if appropriate) back to the requesting application in language of the platform neutral 

18 environment 402. It is recognized that if the requesting application 400 was expressed in a 

19 language other than that of the platform neutral environment 402, then the handler 122 would 

20 convert the response 406 back into the language of expression of the, for example native based, 

21 application B. 
22 



1 Referring to Figure 4, to publish and register its API 124, the Application A,B or its 

2 Handler 122 can register with the interaction module 312 during provisioning. The registration 

3 of the application API 124 can include the following: API Publishing; and API instance 

4 registration. It is recognized that the registration logic could optionally include associated 

5 keywords for the dynamic lookup of the Application 107 and/or associated API 124. 
6 

7 For example, the Application 107 can be developed with built-in knowledge of other 

8 applications 107 that coexist on the terminal 107 and be aware of the identifiers and API 

9 Descriptors, represented by the tables 300, 302 for all applications 107 it can target for access. 

10 In a general case the application 107 deployment model is flexible and newly provisioned 

1 1 applications 107 do not have knowledge of already deployed applications 107 on the terminal 

12 100. In order to enable communications with other applications 107, the requesting application 

13 400 could utilize a dynamic API lookup mechanism. For example, the application could be 

14 developed with the optional ability to export or import data in regard to external APIs 124, send 

15 messages, or call external applications 107 using dynamic discovery of the required API 124 by 

16 a search threshold, such as but not limited to a keyword scoring method. 
17 

18 When registered with the interaction module 312, the application 107 would lookup all 

19 required APIs 124 for other external applications 124 (for both remote and local applications 

20 107) by submitting predefined sets of keywords characterizing these APIs 124. The interaction 

21 module 312 runs the lookup, matching submitted keywords with the keyword set of other 

22 applications 107 (or handlers 122), that were submitted upon publication of their access APIs 

23 124 with the interaction module 312 and placed in the corresponding tables 300, 302. The 



1 interaction module 312 could utilize different matching algorithms to identify the best match for 

2 the requested API 124. An example algorithm is a keyword match counting that would return 

3 the API 124 with the highest score. More advanced algorithms such as scoring of weighted 

4 keywords or a combination match could also be applied. The following example shows API 124 

5 lookup using the simple keyword scoring algorithm. 
6 

7 Example: API lookup using keyword scoring algorithm, referring to Figure 3. 

8 1 . Application A is a Calendar application 107 that registers its API 124 in the table 302 

9 specifying API keywords 'CALENDAR', 4 APPOINTMENT' and 'MEETING'. 

10 2. Application B is a Holiday Viewer application 107 and registers its API 124 specifying API 

1 1 keywords 'CALENDAR' and 'HOLIDAY'. 

12 3. Based on the above, an Application C is a Service Call Planner application 107 executing a 

13 dynamic lookup using the API 124 lookup keywords 'CALENDAR' and 'APPOINTMENT'. 

14 Accordingly, the interaction module 312 returns the API Descriptor of application A from the 

15 table 302, as it scored more in keyword match. The Application C can validate the retrieved API 

16 Descriptor and, if satisfactory, could lookup the corresponding application 107 (or handler 122) 

1 7 identifier via the table 300 for the returned API instance. In this example, Application C would 

18 then access application A (e.g. best match) using the standard interaction protocol of the 

19 interaction module 3 12 as described above in reference to Figure 4. 
20 

21 The Integration Engine 

22 Referring to Figure 5, a further example of interface module 312 is an Integration Engine 

23 (IE) 500 as part of the terminal execution environment of the framework 206. The Integration 

24 Engine (IE) 500 can dynamically extend the published API and processes interactions between 



1 Applications 107 and the API Handlers 122 (see Figure 4). The IE 500 consists of the Service 

2 Provider Interface (SPI) component or extension interface 502, the API Query And Registration 

3 component 504, and Execution API logical components 506. The Integration Engine 500 can be 

4 referred to as a group of software/hardware components designed to: support interaction using 

5 standard interfaces (e.g. XML-to-native call translation) by enabling terminal 100 hosted 

6 applications 107 to access any published API 124 through the table 302; provide dynamic API 

7 124 publishing, lookup, and discovery; offer the registration Service Provider extension Interface 

8 502 for plug-in handlers 122 and applications 107 for provisioning of new API Handlers 122 or 

9 Applications 107; expose the interface component 504 for publishing and registration of 
10 Application Profiles and API Descriptors through the tables 300, 302. 

11 

12 Accordingly, in general, the Integration Engine 500 is a logical group of the device 

13 execution environment components dealing with interaction of device-hosted or remote 

14 applications 107. The Integration Engine 500 is designed to support the platform neutral 

15 interaction mode, interface publishing, and dynamic application 107 and/or application handler 

16 122plugin. 
17 

18 Service Provider Interface 502 

19 Referring to Figures 3 and 5, after publishing the API 124, the Application 107 or the 

20 associated Access Handler 122 register with the Integration Engine 500 as API instances. The 

21 API 124, handler 122, and application 107 publication information is registered with the 

22 appropriate tables 300, 302. The Service Provider extension Interface 502 supports dynamic 

23 plugin of Access Handlers 122 and Applications 107, i.e. the integration engine 500 requests the 

24 application manager 306 to search the tables 300, 302 for the appropriate requested application 



1 107 and/or handler 122. If not found locally on the terminal 100, then the terminal 100 can 

2 canvas the repository 126 (see figure 1) for the required handler 122, API 124, and/or application 

3 107. It is recognized that the extension interface 502 allows plugin of different types of Access 

4 Handlers 122, according to the specific language environments of the external applications 107. 

5 

6 Query and Registration 504 

7 The Query And Registration Interface 504 supports registration 508 of an Application 

8 Profile in the table 300 and publishing of Access Descriptor in the table 302. For the caller, it 

9 also supports lookup access 510 to this table information. The lookup interface 510 is 

10 considered to be optional functionality. Alternatively, the requesting application 400 may be 

1 1 aware of the target application location and Access API Descriptor and may not need to perform 

12 the lookup. 
13 

14 The application 107 or its Handler 122 could publish the API 124 in the table 302 using 

1 5 this example interface 508 : 

16 publishAPI [string : apilD, XML : apiDesc, stringf] : keywords]. 

17 The application 107 or its Handler 122 registers as an instance of this AP 1241. The URI 

18 parameter is that of the application 107 or of its associated Handler 122. 

19 register APIInstance [string : URI, string : apilD]. 

20 The application 107 could dynamically lookup an external API 124 from the table 302 using: 

21 lookupAPI [string[] : keywords] returns [XML : apiDescription ] 

22 lookuplnstance [string : apilD] returns[string[] URIs] 



1 

2 Execution API 506 

3 The execution API interface 506 could be defined as the following calls including request 

4 content related to the access information contained in the tables 300, 302: 

5 submit [XML : params]; or 

6 submit [string : URI, XML : params]. 

7 With the first call shown above, the application URI is not specified. The integration 

8 engine 500 would issue a broadcast call to all applications 107 registered as instances for this 

9 API 124 to achieve access to the requested external application 107. In the second case, the 

10 requesting Application 400 (see Figure 4) specifies the target application 107 explicitly through 

1 1 the URL Accordingly, the API execution interface 506 of the integration engine 500 coordinates 

12 the request and provision of selected APIs 124 according to the needs of the requesting 

1 3 application 400 (see Figure 4). 
14 

15 Referring to Figure 6, an example interaction, illustrating runtime logic flow of the 

16 integration engine 500, between applications A and B is shown. Application B requests to 

17 access the API 124 of application A via the execution interface 506. The execution interface 506 

18 queries the Query And Registration Interface 504 to lookup handlers 122 and/or applications 107 

19 registered with the requested API 124 via the table 302. The interface 504 retrieves the 

20 appropriate handler 122 for the requested application A by noting in the table 302 that the 

21 application A is not expressed in the platform neutral environment 402, hence the handler 122 is 

22 required for operation in the environment 402. The registered Handler 122 is then used by the 

23 integration engine 500 for facilitating access of the Application B to the Application A, via 



1 calling of the appropriate API 124 for the application A. It is recognized that the handler 122 

2 and corresponding API 124 have previously been registered as instances of the application A 

3 through the interface 504. 
4 

5 Referring to Figures 5 and 7, operation 700 of the integration engine 500 by adding a 



6 Handler to support application 107 interactions, API 124 registration steps, and steps executed 

7 upon the application 107 issuing the request for the API 124. It is noted that this example does 

8 not use the optional lookup search functionality. The Integration Engine 500 on the terminal 100 

9 can support XML-based interaction protocol for use as the platform neutral environment 402, 
10 such as in the example below. 

11 

12 At step 701, a Calendar application 107 'PersonalCalendar' is provisioned to the terminal 

13 100 and doesn't have the built-in knowledge of the Integration Engine 500 interaction standard. 

14 At step 702, a Calendar Handler 122, designed to enable IE 500 standard access (represented by 

15 environment 402) for the Calendar application 107, is plugged in to the IE 500 through the 

16 extension interface 502 as an instance of 'PersonalCalendar' API(s). For example, the API 

17 Descriptor corresponding to the plugin handler 122 could be as follows: API 124 to update 

18 Calendar application 107 supports an operation 'addMeeting' to add a meeting. It is published in 

19 the table 302 with the following descriptor 'updateCalendarDesc.xml': 



20 <! DOCTYPE action SYSTEM "api.dtd" > 

21 <action api="updateCalendar"> 

22 <op name-'addMeeting" > 

23 <param>Meeting</param> 

24 <result type="boolean" /> 

25 </op> 

26 </action> 

27 



1 At step 703, the Calendar Handler 122 publishes through the interface 504 the API(s) 124 

2 with an API-ID 'updateCalendar' as; publish APIf" updateCalendar", 

3 "updateCalendarDesc.xml"). The Calendar handler 122 at step 704 then is registered through 

4 the interface 504 as "personalCalendarHandler" with the IE 500 as an instance of 

5 updateCalendar API 124 as follows: register APIInstanceC'personalCalendaxHandler" , 

6 "updateCalendar"). It is recognized that the table 302 includes APIs 124 and handlers 122 that 

7 are registered as instances of the provisioned applications on the terminal 100. At step 706, a 

8 requesting application 400 (see Figure 4) builds the request info 'addMeetingRequest.xml' in 

9 order to add a meeting: 

1 0 <action api=7/updateCalendar"> 

1 1 <op name="addMeeting" > 

12 <param> 

13 <Meeting> 

14 <date>09/15/03 10:15:00</date> 

1 5 <details>Conference call with John</details> 

16 <note>To discuss the idea of XML based lnterface</note> 

17 </Meeting> 

1 8 </param> 

1 9 <result type="boolean" /> 

20 </op> 

21 </action> 

22 
23 

24 At step 708, Option 1 (directed access) provides for the Application 400 sending the 

25 following request to the Integration Engine 500: 

26 submitf'/local/personalCalendarHandler", "addMeetingRequest.xml'] . Otherwise, at step 710 

27 Option 2 (broadcast) provides for the Application 400 sending the following request to the 

28 Integration Engine 500: submit ["addMeetingRequest.xml"] . At step 71 1, the IE 500 passes the 

29 request on to the Calendar Handler 122 (and to other registered 'updateCalendar' API 124 

30 instances with option 2) as noted in the table 302. The Calendar Handler 122 verifies 712 the 

3 1 data (e.g. date) and builds the input in a format expected by the Calendar Application 107 (e.g. 

32 creates native Date object, constructs native Meeting object, etc.). The Calendar Handler 122 



1 then invokes 714 Calendar application 107 native API 124 call Upon completion, the Calendar 

2 Handler 122 passes 716 results (if appropriate) to the Integration Engine 500 for delivery to the 

3 requesting application 400. 
4 

5 It is recognized that similar steps (without the handler 122) would be encountered above 

6 for API 124 registration and access without need of the handler 122 (i.e. the calendar application 

7 is expressed in the platform neutral environment 402 compatible language). Further, the access 

8 of the calendar handler in step 708 could be implemented remotely, if desired. 
9 

10 In view of the above system 10, utilization of the Publishing and Accessing of 

1 1 Application APIs 124 through the interface module 312 (or expressed as the engine 500) 

12 provides for generic and extensible inter-application 107 interactions and supports a dynamic 

13 environment for application 107 interaction. The applications 107 are enabled to interact in a 

14 platform neutral manner using such as but not limited to a structured language (e.g. XML) and/or 

15 platform neutral scripting (e.g. ECMAScript). The applications 107 can dynamically discover 

16 available APIs 124 and handlers 122 using the optional lookup interface 510, such as but not 

17 limited to using a keyword matching pattern. Further, the system 10 can provide the ability to 

18 dynamically extend the application 107 environment and set of provided API's 124 using 

19 dynamic plugin of Access Handlers 122 through the extension interface 502. It is further 

20 recognized that the interface module 312 could have similar interfaces 502, 504, 506, 508, 510 to 

21 that of the integration engine 500. 
22 



1 Further, the inter-application 107 communications are facilitated by the following 

2 constructs: Application Profiles of the table 300; Application API and handler Descriptors of the 

3 table 302 ; and Application API Interaction Interfaces involving registration, lookup, and access. 
4 

5 The above description relates to one exemplary systems and methods. Many variations 

6 will be apparent to those knowledgeable in the field, and such variations are within the scope of 

7 the application. For example, although XML and a subset of ECMAScript are used in the 

8 examples provided, other languages and language variants may be used. Further, it is 

9 appreciated that the system 10 can be implemented as hardware and/or software components 

10 including: a data structure module for registering the access information of the target application, 

1 1 the access information including published access information; an interface module for providing 

12 the platform neutral environment, the interface module configured for receiving an access 

13 request from the requestor application; and an interface component module configured for 

14 containing an interface element retrievable by using the request content. 
15 



